home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2331 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 30 Jan 1996 09:53:24 +0100
  6. Organization: dis-
  7. Distribution: inet
  8. Message-ID: <4ekma4$8b@serpens.rhein.de>
  9. References: <4e8h9j$mp5@sinsen.sn.no> <4e8pk2$ntm@serpens.rhein.de> <3873.6603T379T952@wr.com.au>
  10. NNTP-Posting-Host: serpens.rhein.de
  11.  
  12. accolyte@wr.com.au (Accolyte) writes:
  13.  
  14. >> You are already dead at that point because you don't know how to
  15. >> handle incoming interrupts.
  16.  
  17. >What??!? :) I know very well how to handle interrupts. You don't need
  18. >the system for it.
  19.  
  20. Don't laugh. You do not know how to handle interrupts from sources you
  21. do not know.
  22.  
  23. >>>C0d3rz  that  produce  bad code are not C00l at all.
  24. >> No ? But they act as if they were.
  25.  
  26. >You're avoiding his point, again.
  27.  
  28. I don't think that he has a point here.
  29.  
  30. >Yes you do. You say anyone who programs without the OS sucks.
  31.  
  32. No, I don't. I say that everyone who programs _against_ the OS and
  33. who relies on pure assumptions produces bad code.
  34.  
  35. >> be measured in number of pixels you set in an effect. Game quality
  36. >> is not.
  37.  
  38. >Name some OS-friendly games, and some hardware-bashing game. Then
  39. >lets compare the quality.
  40.  
  41. Unless you can prove that the hardware-bashing games are of higher
  42. quality than the OS-friendly games _because_ of their hardware-bashing
  43. that's a pretty meaningless comparison.
  44.  
  45. >His description of how to take over the machine was good and valid.
  46.  
  47. No, that's wrong.
  48.  
  49. >He DOES know it's slow. He hasn't tried it, but it's as obvious as
  50. >the chip on your shoulder that using a subrotine to plot a single
  51. >pixel is gonna be as slow as hell.
  52.  
  53. And it is as clear that people like you always refer to "calling
  54. a subroutine to plot a single pixel" when it comes to OS programming.
  55.  
  56. >On the same note, have you tried hardware programming?
  57.  
  58. Sure. Not that much on Amiga though. But when it comes to write software
  59. for your own hardware you can't avoid hardware programming.
  60.  
  61. >If you expect
  62. >him to understand OS routine, I expect you to understand hw programming.
  63.  
  64. So what ?
  65.  
  66. >> way because nobody notices. Gameplay doesn't suffer if you can render
  67. >> 10% less pixels but the c0d3rz' ego does suffer.
  68.  
  69. >10% a ridiculously small figure.
  70.  
  71. No.
  72.  
  73. >Well optimised hardware bashing code
  74. >are much faster than system routines,
  75.  
  76. If you believe that you have to always "call a subroutine to plot a single
  77. pixel" then this is right.
  78.  
  79. But then you don't have to.
  80.  
  81. >to make out. Have you ever coded something decent through the hardware
  82. >only? Do you even know what the hell you're arguing about?
  83.  
  84. *sigh*
  85.  
  86. >>>Do you seriously believe
  87. >>>that  a standard A1200 would have had any great games if everybody used
  88. >>>the OS?
  89. >>
  90. >> Sure.
  91.  
  92. >You are mistaken.
  93.  
  94. Well, then let me clarify. If something is preventing great games by using
  95. the OS then it is the c0d3rz.
  96.  
  97. >>>I dare you to name ONE great game using *only* the OS!
  98. >> I dare you name one c0d3r that actually tried.
  99.  
  100. >There you go again, avoiding the question because you can't answer it.
  101.  
  102. I can answer it. But then you will reject my idea of "great game".
  103.  
  104. >Whether a hw-coder tried or not is irrelevant.
  105.  
  106. No, it isn't. You argue that the OS is bad (for game programming) because
  107. otherwise there would be great games that used the OS. Don't you think there
  108. could possibly be other reasons ?
  109.  
  110. >Not rubbish. Do you think that hw-programming means you can't support
  111. >faster machines?
  112.  
  113. No. I think that faster machines are not supported by c0d3rz. That's a difference.
  114. The reason is that c0d3rz base decisions on mere assumptions (like: "self-modifying
  115. code isn't going to break with caches" or "blitter-nasty will stop the CPU until
  116. the blit is done").
  117.  
  118. >> Maybe it is not fast enough (which I don't believe and which is only
  119. >> half of the story anyway). But the problem is that this argument comes
  120. >> independent of the hardware you do have which simply means that the
  121. >> argument is wrong and you must have another reason.
  122.  
  123. >Er.. interesting logic there ;)
  124.  
  125. Well, either my logic is right or there is no logic reason for c0d3rz to
  126. bang hardware.
  127.  
  128. >We should really get you into IRC one time, this isn't getting anywhere
  129. >in messaging.
  130.  
  131. Ah.. That's again _pure_ c0d3r style. Why do you assume that I am _not_ on IRC ?
  132. Did you ever have a look ?
  133.  
  134. -- 
  135.                                 Michael van Elst
  136.  
  137. Internet: mlelstv@serpens.rhein.de
  138.                                 "A potential Snark may lurk in every tree."
  139.